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APPEAL BRIEF 

Mail Stop Appeal Brief Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

This Appeal Brief is submitted pursuant to the Notice of Appeal received in the U.S. 
Patent and Trademark Office on February 12, 2009, and in support of the appeal from the final 
rejection(s) set forth in the Office Action mailed on September 10, 2008. The fee for filing a 
brief in support of an appeal is enclosed. A Petition for Extension of Time and the appropriate 
fee are being filed concurrently. 

I. REAL PARTY IN INTEREST 

The real party in interest is EqualLogic, Inc., 300 Innovative Way, Suite 301, Nashua, 
NH 03062. EqualLogic, Inc. is the Assignee of the entire right, title and interest in the subject 
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application, by virtue of an Assignment recorded on January 21, 2004 at Reel 014930, Frames 
0827-0830. 

II. RELATED APPEALS AND INTERFERENCES 

Appellants, the undersigned Attorney, and the Assignee are not aware of any related 
appeals or interferences which will directly affect or be directly affected by or have a bearing on 
the Board's decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 1 through 10, 12, 14 through 21 and 23 have been finally rejected, and a copy 
appears in the Appendix of this Brief. Claims 1,9, 12, 14, 21 and 23 were last amended in the 
Amendment filed on June 1, 2006. Claims 2 through 8, 10 and 15 through 20 appear as 
originally filed. Claims 11, 13, 22 and 24 were canceled. Claims 1-10, 12, 14-21 and 23 are 
being appealed herein. 

IV. STATUS OF AMENDMENTS 

No amendments are being made concurrently with this Appeal Brief. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 
Claim 1 

Claim 1 is directed to an apparatus for data storage resource migration. The apparatus 
comprises a plurality of storage servers each having a set of resources partitioned thereon. The 
storage servers each also have a load monitor process capable of communicating with other load 
monitor processes for generating a measure of loading on respective ones of the plurality of 
servers. The apparatus also transfers resources from one of said plurality of servers to another 
server in response to the measure of loading. A write-detect process detects when a resource 
write request is being made to a portion of a partitioned resource that is in a process of being 
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moved from the first server to a partitioned second server. In response to a write failure, on the 
second server, the migration process for that resource is restarted. 

Support for Claim 1 can be found in the application as originally filed at least at page 4, 
line 26 through page 5, line 17; page 12, line 25 through page 15, line 5; Tables 1 and 2; and 
Figure 8. 

Claim 6 

Claim 6 depends from Claim 1 and adds a requirement that the system determine whether 
a server is servicing a disproportionate share of client requests. 

Support for this claim is found at least at page 17, line 19 to 29; Figure 8, and elsewhere. 

Claim 8 

Claim 8 also depends from Claim 1 and adds that a routing table is used for tracking 
resources maintained on the system. 

Support for this claim is found at least at page 16, lines 12 to 19; Figure 8 and elsewhere. 

Claim 14 

Claim 14 directed to a process for moving resources across a plurality of storage servers 
with a set of resources partitioned thereon. The process comprises steps for monitoring a server 
load, communicating with other load monitor processes for generating a measure of loading, 
transferring as function of the measured load a resource from one server to another server, 
detecting when a resource write request applies to a resource that is in the process of being 
moved from one server to another, and in response to a write to failure on the second server, 
restarting the migration process. 

Support for this claim is found at least at page 4, line 26 through page 5, line 17; page 12, 
line 25 through page 15, line 5; Tables 1 and 2; and Figure 8. 



Claim 17 

Claim 1 7 depends from claim 14 and includes a further step of determining whether a 
server is servicing a disproportionate share of client requests. 
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Support for this claim is found at least at page 17, lines 19 through 29; Figure 8 and 
elsewhere. 

Claim 19 

Claim 19 depends from claim 14 and includes a further step of maintaining a routing 
table for tracking resources maintained by the system. 

Support for this claim is found at least at page 16, lines 12 through 19; Figure 8 and 
elsewhere. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-10, 12, 14-21 and 23 are properly rejected under 35 U.S. C. 103(a) as 
being obvious over Blumenau, et al (U.S. Publication 2004/0080558). 

VII. ARGUMENT 

There are several reasons why Blumenau fails to render the claimed invention obvious. 

The Applicants ' Claimed Invention 

The Applicants' invention is directed to approaches for controlling a server-based, 
partitioned resource, storage system. In such a system, a plurality of storage servers store a set of 
partitioned resources. The resources are "partitioned", meaning that portions of a given resource 
are stored on one server, and other portions of that very same resource are stored on other 
servers. The storage servers each have a respective load monitor processes that communicates 
with the load monitor processes in the other servers to determine a measure of loading at each 
respective storage server. Based on this determined measure of loading, portions of the 
partitioned resources are transferred back and forth, from one server to another, in a so-called 
"migration". A write detect process detects when a resource is in the process of being moved 
("migrated") between a source server (the "first server") and a second server (the "target 
server"). 

The claims are specifically directed to what happens when a write failure occurs on the 
target server (i.e., the "second server" as recited in the claims) during migration. This is handled 
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in a simple and efficient way - by restarting the migration process for the portion of the resource 

which experienced the failure. 

Accordingly, Claim 1 recited in pertinent part: 

a resource migration process for transferring a resource . . . 
in response to said measure of loading; 
a write-detect process which: 

(i) detects when a resource write request applies to a 
resource that is in the process of being moved from a first 
server to a second server . . .; and 

(ii) in response to a write failure on the second server, 
restarts the migration process. 



1. Blumenau does not detect target server write failures in a resource migration 
process, and in response thereto, then restart that very same migration process . 

Blumenau discloses a write error recovery process, and to that extent, is similar to 
Applicants' claimed invention. Blumenau specifically compares source and target data with 
state information to determine which data is still "good" and which data is "bad" (see paragraph 
[0048], lines 2-5 and paragraph [0049], lines 2-7). For example, the state information may be a 
count which indicates the number of data base operations performed on a particular storage 
location (see paragraph [0051]). Blumenau's recovery process then specifically copies the good 
data from the storage location where the write completed successfully to the other location, 
based on the state information. See paragraph [0048], lines 5-7 and [85], lines 9-12. 
Alternatively, Blumenau's recovery process can invalidate data stored at both locations. See 
paragraph [0048], lines 20-23 and paragraph [85], lines 9-11. 

The Examiner points to Blumenau at paragraphs [0039 through 0040] as supposedly 
teaching the features of almost all of Applicants' invention. The Examiner furthermore believes 
that Blumenau's paragraph [0042] discloses that when the write is not completed, "a migration 
process is restarted", pointing to Blumenau's specific statement that the "DBMS will reissue the 
request". 

However, the mere suggestion that a Data Base Management System (DBMS) reissue a 
write request for a particular piece of data is not the same thing as restarting a resource migration 
process . Applicants' claimed resource migration is the process of moving a portion of a 
partitioned resource (e.g., a large chunk of data) to a different location. The claimed invention 
requires attempting to move the entire resource once again. Blumenau is suggesting only that a 
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DBMS reissue a specific failed write request at the DBMS level. Applicants' restart of a 
migration process would be transparent to a DBMS. It is not a response to an application level 
failed request to access a specific database record. 

In other words, Blumenau is referring to a high level application (i.e., a database 
management system) reissuing a write request when that write operation has not been completed 
within a certain amount of time. 

Applicants, on the other hand, restart an entire resource migration process (i.e., at a lower 
level which would be invisible to an application level DBMS process). 

According to paragraph [0048] of Blumenau, undesirable states may be eliminated by a 
recovery process that determines whether or not the source and target data is consistent and when 
it is not, takes action to make the data consistent. For instance, to recover from an interrupted 
migration, a comparison can be made between the state information for corresponding data 
storage locations in the source and target volumes. If, after the comparison, it is determined that 
a more recent write operation was performed to either of the source or target data storage 
locations, that data stored in that particular data storage location may be relied upon as good 
data. 

Again, Blumenau is clearly only suggesting a much more involved process of checking to 
see whether each data write operation was actually successful or not. This, again, is not the same 
thing as, or suggestive of, restarting an entire migration process. 

With respect to other aspects of the Examiner's argument, we note that Blumenau also 
does not actually disclose that the server processes communicate with each others to generate a 
measure of loading on the respective servers as claimed. The Examiner points to Blumenau's 
state table 105 as providing this information. However, that table stores state information 
concerning backup, copy, and recovery. It does not include, suggest or teach maintaining a data 
indicative of load across a plurality of servers or doing anything in response to the same, never 
mind restarting a migration process, as claimed. 

2. Blumenau teaches away as he requires keeping state information . 
Applicants also note that Blumenau requires that write state consistency information be 
maintained. Indeed, Blumenau specifically states his is a technique for recovering the state of 
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write process without having to reperform operations that were completed successfully before 
the interruption (see the Abstract and paragraph [0029]). In contrast to this, Applicants' 
invention does not maintain state information, and specifically requires restarting the migration 
process. 

Blumenau uses a state information table 105 that stores the state of pending I/O 
operations. As explained in paragraph [0034], the state information table 105 provides an 
indication of the status of input/output (I/O) operations performed on one or more storage 
locations of storage system 102. Blumenau then goes on to explain that when a write is 
performed on one or more portions of data 203 on volume 201, an indicator is updated in the 
state change information table (Blumenau, paragraph [0034]). This information is a bit that 
indicates that a change has been made to the data stored in a corresponding storage location. 

In other words, Blumenau only teaches one to store state information to enable picking 
up exactly from where the error occurred. It thus teaches away from restarting, from the 
beginning, a write recovery process. 

Claim 6 should be allowed. 

There are additional reasons why at least Claim 6 should be allowed. The Examiner is of 
the opinion that the prior art further discloses that a load monitor process determines when a 
server is servicing a disproportionate share of client requests in a server group. The Examiner 
refers to Blumenau's paragraph [0064] for supposedly teaching this feature. There is a mention 
in that paragraph of monitoring when the storage system becomes "processor bound", 
"approaching its performance limit", or its "storage capacity". But these do not amount to a 
teaching, suggestion or even any inference that there is any determination of which share of 
client requests are being handled by a specific server, as claimed. 

Claim 6 should therefore be allowed. 

Claim 8 should be allowed. 

Blumenau admittedly does disclose a state information table that is used to track the state 
of a storage element in a logical volume. For example, in paragraph [0051] is explained that 
state information 301 may include a count 302 which indicates a number of data operations 
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performed on a corresponding storage element of volume 303. It is also stated in paragraph 
[0054] that state information may include other information used for recovery, such as to track 
information as needed for disk mirror processes. 

However, there is no mention, suggestion, or teaching in Blumenau that this state table is 
used to perform any routing function among equivalent servers, or maintain data that would 
permit request routing based on the same. 

Applicants' Claim 8, on the other hand, is directed to a routing table for tracking which 
resources are maintained on which servers in the system. Since Blumenau does not even 
disclose a plurality of storage servers that share a set of resources partitioned thereon, there is no 
need for him to either maintain such a routing table or determine how to route client requests 
among servers. 

The Examiner also argues that paragraph [0064] in Blumenau teaches that a load monitor 
process monitors one or more of network traffic load, I/O request load or storage traffic pattern 
type. But the Examiner is merely repeating Applicants' claim language. None of these functions 
are actually stated in Blumenau, which merely determines when a storage system "becomes 
processor bound", "approaches a performance limit", or is "reaching storage capacity limits". 
These do not amount to teaching the more specifically claimed aspects monitoring of traffic load, 
I/O request load, or storage traffic pattern type. 

Claim 8 is patentable over Blumenau. 

Claims 14, 17 and 19 are also patentable. 

Claim 14 is a method claim that recites: 

A process for moving resources across a storage system having a plurality 
of storage servers with a set of resources partitioned thereon, comprising . . . 
monitoring a load on a server. . .; 

transferring, as a function of the measured loads, a resource from one of 
said plurality of servers to another . . . 

detecting when a resource write request applies to a resource that is in the 
process of being resolved . . .; and 

in response to a write failure . . . restarting the migration process. 

Claim 14 thus contains method steps that have corresponding features in claim 1 . Claim 
14 is thus allowable for the same reasons stated above for claim 1 . 
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Claim 17 and 19 depend from claim 15 and recite method steps corresponding to features 
of claim 6 and 8, respectively. Claims 17 and 19 are thus patentable for the reasons stated above 
for claims 6 and 8. 

Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 




By_ 

David J. Thibodeau, Jr. 
Registration No.: 31,671 
Telephone: (978) 341-0036 
Facsimile: (978)341-0136 



Concord, MA 01742-9133 
Dated: rn^ 11,10 0*1 
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CLAIMS APPENDIX 
An apparatus for resource migration, comprising a storage system having 

a plurality of storage servers with a set of resources partitioned thereon, said 
storage servers having a load monitor process capable of communicating with other load 
monitor processes for generating a measure of loading on respective ones of the plurality 
of servers; 

a resource migration process for transferring a resource from one of said plurality 
of servers to another of said plurality of servers in response to said measure of loading; 

a write-detect process which: 

(i) detects when a resource write request applies to a resource that is in the 
process of being moved from a first server to a second server, and which in response to 
such resource write request writes copies of the resource of both of said first and second 
server; and 

(ii) in response to a write failure on the second server, restarts the migration 
process for the resource to ensure that the write request is propagated to the second 
server. 

The apparatus of Claim 1 , wherein said servers are equivalent to each other. 

The apparatus of Claim 1, wherein said resources are selected from the group consisting 
of data blocks, program files, multimedia files, applications, and database files. 



The apparatus of Claim 1, wherein said measure of loading reflects both a storage system 
load and a server load. 

The apparatus of Claim 1 , wherein said storage system is a Storage Area Network. 

The apparatus of Claim 1 , wherein the load monitor includes a process to determine 
whether a server is servicing a disproportionate share of the client requests being handled 
by a server group. 

The apparatus of Claim 1, wherein the resource migration process includes a block data 
migration process. 

The apparatus of Claim 1, further including a routing table for tracking resources 
maintained on the system. 

The apparatus of Claim 1, wherein a pointer to a resource is maintained during an access 
operation to provide continuous data access. 

The apparatus of Claim 1, wherein the load monitoring process monitors one or more of 
network traffic load, I/O request load, storage traffic pattern type. 

(Canceled) 

The apparatus of Claim 1 , wherein the resource migration process divides the resource 
being moved into smaller subresources, and wherein the write-detect process; 

(i) detects when a resource write request applies to a subresource that is in the 
process of being moved from a first server to a second server, and in response to such 
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resource write request writes copies of the subresource to both of said first and second 
server; and 

(ii) wherein restarting the migration comprises restarting the migration for the 
subresource. 

(Canceled) 

A process for moving resources across a storage system having a plurality of storage 
servers with a set of resources partitioned thereon, comprising the steps of 

monitoring a load on a server and communicating with other load monitor 
processes for generating a measure of loading on respective ones of the plurality of 
servers; 

transferring, as a function of the measured loads, a resource from one of said 
plurality of servers to another of said plurality of servers in response to said measure of 
loading; 

detecting when a resource write request applies to a resource that is in the process 
of being moved from a first server to a second server, and in response to such resource 
write request writing copies of the resource to both of said first and second server; and 

in response to a write failure on the second server, restarting the migration process 
for the resource to ensure that the write request is propagated to the second server. 

The process of Claim 14, wherein said servers are equivalent to each other. 
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16. The process of Claim 14, measuring a load includes measuring a storage system load and 
a server load. 

1 7. The process of Claim 14, including the further step determining whether a server is 
servicing a disproportionate share of the client requests being handled by a server group. 

1 8. The process of Claim 14, wherein the resource migration process includes -a block data 
migration process. 

1 9. The process of Claim 1 4, further including maintaining a routing table for tracking 
resources maintained on the system. 

20. The process of Claim 14, wherein the load monitoring process monitors one or more of 
network traffic load, I/O request load, storage traffic pattern type. 

2 1 . The process of Claim 14, further including maintaining a pointer to a resource during an 
access operation to provide continuous data access. 

22. (Canceled) 

23. The process of Claim 14, further including: 

dividing the resource being moved into smaller subresources; 

detecting with the write-detect process when a resource write request applies to a 
subresource that is in the process of being moved from a first server to a second server, 
and in response to such resource write request writing copies of the subresource to both 
of said first and second server; and 
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wherein restarting the migration comprises restarting the migration for the sub 
resource. 



24. (Canceled) 
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EVIDENCE APPENDIX 



None. 
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RELATED PROCEEDINGS APPENDIX 



None. 



